home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1993…ch: Other People's Memory / ADC Developer CD (1993-03) (''Other People's Memory'')_iso / Dev.CD Mar 93.iso / Development Platforms / Apple II / Essentials / Technical.Notes / IIGS / TN.IIGS.051 < prev    next >
Encoding:
Text File  |  1992-07-15  |  6.3 KB  |  160 lines  |  [TEXT/GEOL]

  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5. Apple IIgs
  6. #51: How to Avoid Running Out of Memory
  7.  
  8. Revised by: Dave Lyons                                               May 1992
  9. Written by: Eric Soldan                                          January 1989
  10.  
  11. This Technical Note discusses handling nearly-out-of-memory situations when
  12. working with the IIgs tools.
  13.  
  14. CHANGES SINCE SEPTEMBER 1990:  Added discussion of an Out-of-memory routine
  15. problem fixed in System 6.0.
  16. _____________________________________________________________________________
  17.  
  18.  
  19. INTRODUCTION
  20.  
  21. Running out of memory is a concern for most every application.  Working with
  22. the Toolbox makes monitoring this situation a little more difficult since your
  23. application is not the only one allocating memory.
  24.  
  25. Low-level toolbox functions (for example, QuickDraw II calls) require that a
  26. 16K block of memory be allocatable, while high-level routines (for example,
  27. the Window Manager) require that a 32K block of memory be allocatable.  Apple
  28. does not guarantee that toolbox functions behave reasonably if there is less
  29. memory available, and the tools are not stress-tested with less than the
  30. minimum required memory available.
  31.  
  32. Since the toolbox assumes reasonable memory-allocation requests succeed, just
  33. waiting for an out-of-memory error is not adequate memory management.  To make
  34. your application work reliably in low-memory situations, you need a method of
  35. ensuring that the toolbox gets memory when it needs it.  This Note describes
  36. two approaches.
  37.  
  38.  
  39. HOW MUCH MEMORY CAN BE ALLOCATED
  40.  
  41. There's no way to tell how much memory can be allocated without actually
  42. trying to allocate it.
  43.  
  44. MaxBlock tells you the size of the largest single free block, but this doesn't
  45. take into account purgeable blocks, compaction, and out-of-memory routines
  46. (see Apple IIgs Toolbox Reference, volume 3).  FreeMem and RealFreeMem cannot
  47. tell you how badly fragmented the memory is, and they do not take into account
  48. out-of-memory routines.
  49.  
  50.  
  51. A SUGGESTED METHOD
  52.  
  53. A method of checking for a nearly-out-of-memory condition is to have your own
  54. purgeable handle just for this task.  If the handle has not been purged, then
  55. you have plenty of memory for the toolbox, and in the worst case, the toolbox
  56. purges your handle if it needs the RAM.
  57.  
  58. The less often your purgeable handle gets purged, the better performance you
  59. get in nearly-out-of-memory situations.  Therefore, you should arrange for
  60. other purgeable memory, not necessarily belonging to your application, to be
  61. purged before your handle.  For example, you want dormant applications to be
  62. purged, rather than having your handle get repeatedly purged and reallocated.
  63. So the purge level of this handle should be one.
  64.  
  65. The check to see if a handle has been purged is very fast.  If it has been
  66. purged, you have to try to reallocate it.  Reallocating a handle is not a fast
  67. process, so the fewer times the handle is purged, the faster the check is and
  68. the better your performance.  Unless you are in a nearly-out-of-memory
  69. situation, the handle should not be purged at all, and you should have
  70. virtually no overhead for this process.
  71.  
  72. This technique can be implemented as follows:
  73.  
  74.  
  75. appStart
  76. ;
  77. ; Somewhere at start, create a purgeable handle of size N,
  78. ; called "loMemHndl", purge level 1.
  79. ;
  80.                  rts
  81.  
  82. ******************
  83. ;
  84. ; Here's an example of checking for nearly-out-of-memory:
  85. ;
  86.                  jsr    preCheckLoMem
  87.                  bcc    goForIt
  88.                  bcs    HandleError        ;Handle errors appropriately.
  89. goForIt          (_ToolboxCall[s])         ;Make as many as needed.
  90. ;
  91. ; Here you can make your toolbox calls.  Since you prechecked
  92. ; for nearly-out-of-memory conditions, you should have no memory
  93. ; errors at this point.
  94. ;
  95. ; You could also check after calls, as shown here:
  96. ;
  97.                  (_ToolboxCall)
  98.                  jsr    checkLoMem         ;Call this to see if low.
  99.                  bcc    noError
  100.                  bcs    HandleError        ;Take care of errors.
  101.  
  102. noError          jsr    lifeIsGood
  103.                  .
  104.                  .
  105.                  .
  106.                  rts
  107.  
  108. ******************
  109. ;
  110. ; Here are some sample routines to check for the nearly-out-of-
  111. ; memory condition.
  112. ;
  113. checkLoMem       bcs    retErr
  114. preCheckLoMem    lda    [loMemHndl]
  115.                  ldy    #2
  116.                  ora    [loMemHndl],y
  117.                  beq    gotPurged
  118.                  lda    #0
  119.                  clc
  120.                  rts
  121. gotPurged        (Try reallocating it into loMemHndl, purge level 1.)
  122.                  (If you can't, you will get a $0201 error.  You may wish to
  123.                   return the $201 error, or you may wish to change it into
  124.                   your own error code.)
  125. ;
  126. retErr           rts                       ;This is a single exit point
  127.                                            ;whether errors were present
  128.                                            ;or not.
  129.  
  130. You can determine the size of this purgeable handle, but like determining what
  131. size stack is adequate for an application, there is no single "right" answer.
  132. There are different considerations for size of the purgeable handle for each
  133. application, and these may change during the development process.  Use your
  134. best judgement, keeping in mind that high-level toolbox routines require a 32K
  135. block.
  136.  
  137.  
  138. AN ALTERNATIVE
  139.  
  140. For better control over when your handle is purged or disposed, you can write
  141. an out-of-memory routine as described in the Memory Manager chapter of Apple
  142. IIgs Toolbox Reference, volume 3.  Out-of-memory routines have the opportunity
  143. to free up memory before or after the Memory Manager attempts to purge
  144. purgeable handles, and this manual contains a sample of such a routine.
  145.  
  146.    NOTE : If your Out-of-memory routine frees up memory on the
  147.           second pass, there is a problem with the Memory Manager
  148.           in System Software 5.0 through 5.0.4 that may affect
  149.           you.  If your routine frees enough bytes on the second
  150.           pass, but the Memory Manager still cannot complete the
  151.           request it is working on, it can hang for a couple of
  152.           minutes and then crash.  This is fixed in System 6.0.
  153.  
  154.  
  155. Further Reference:
  156. _____________________________________________________________________________
  157.  
  158.    o   Apple IIgs Toolbox Reference, Volumes 1-3
  159.  
  160.